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Application/Control Number: 09/864,935 
Art Unit: 2153 

DETAILED ACTION 

This is a first Office action on the merits of this application, 
presented for examination. 

Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

1 . Claim 2 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

The term "substantially" in claim 2 is a relative term which renders the claim 
indefinite. The term "substantially" is not defined by the claim, the specification does 
not provide a standard for ascertaining the requisite degree, and one of ordinary skill in 
the art would not be reasonably apprised of the scope of the invention. 

2. Claims 1-12 and 18-19 are rejected under 35 U.S.C. 112, second paragraph, as 
being incomplete for omitting essential steps, such omission amounting to a gap 
between the steps. See MPEP § 2172.01. 

Claim 1 describes in the preamble "a method of sending network device 
instructions to a network device." However, the body of the claim does not describe 
either a "network device instruction" or a "network device." Thus, the claim lacks the 
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Claims 1-20 are 
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essential steps linking the networl< device nnentioned in tine preamble with the steps 
claimed in the body of the claims. 

In further discussing claim 1, the claim also lacks essential steps of deriving 
proxy agent instructions from the application instaictions, which would be necessary to 
carry out the step of "uploading proxy agent instructions derived from the application 
instructions to a mail server," and of downloading the proxy agent instructions by a 
proxy agent, which would be necessary to carry out the step of "confirming that the 
proxy agent instructions have been downloaded by a proxy agent." The claim is 
confusing without these essential steps, and the invention as claimed would not operate 
without these steps. 

Claims 2-12 and 18 depend from claim 1 and are therefore rejected as well. 

Claim 19 suffers from the same shortcomings as claim 1 , and is thus rejected for 
the same reasons. 

In a similar manner, claim 5 describes "determining the proxy agent that is 
associated with the network device," but does not describe associating a proxy agent 
with a network device. 

Furthermore, claim 6 describes, "specifying the address of the proxy agent that is 
to execute the proxy agent instructions," but does not describe selecting or choosing a 
proxy agent is to execute the proxy agent instructions. 
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Claim Rejections - 35 USC § 102 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21 (2) 
of such treaty in the English language. 

3. Claims 1-1 1 and 13-20 are rejected under 35 U.S.C. 102(e) as being anticipated 
by L'Heureux et al. (U.S. Patent No. 6,697,942, hereinafter "L'Heureux"). 

In considering claim 1 , UHeureux discloses a method of sending network device 
instructions ("commands") to a network device ("DET") comprising: 

Receiving an application instruction generated by an application (col. 5, lines 40- 
42, 55-59, wherein "GUI software 20" is used to "construct a complex message," which 
is received by a "command formatter 220"); 

Uploading proxy agent instructions derived from the application instructions to a 
mail server (col. 5, lines 55-67, col. 6, lines 1-5, wherein the "command formatter 220" 
converts the application instructions into "multiple data-type commands" and those 
commands are uploaded to the "SMTP server"); and 

Confirming that the proxy agent instructions have been downloaded by a proxy 
agent (col. 6, lines 14-23, 29; col. 8, lines 48-50, wherein the e-mail is "downloaded" to 
the in-box at the DET, and the DET "automatically generates and sends a return e-mail 
message confirming at the embedded DET commands have been executed properly"). 
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In considering claim 2, Examiner has interpreted the term "substantially the 
same" as simply meaning "the same." Thus interpreted, L'Heureux further discloses 
that the proxy agent instructions are the same as the application instructions (both are 
instructing the DET to perform the command). 

In considering claim 3, L'Heureux further discloses encrypting the proxy agent 
instructions (col. 7, lines 60-63, wherein a "security key block" is used to encrypt the 
message). 

In considering claim 4, L'Heureux further discloses authenticating the proxy 
agent instructions (col. 8, lines 4-5, "the decryption module 322 validates the 
message"). 

In considering claim 5, L'Heureux further discloses determining a proxy agent 
that is associated with the network device (col. 6, lines 1-11. wherein the POP server is 
the proxy agent, and the system determines the POP server associated with the 
device). 

In considering claim 6, L'Heureux further discloses specifying the address of the 
proxy agent that is to execute the proxy agent instructions (col. 6, lines 60-65, wherein 
the in-box is the proxy agent and the sender specifies the address of the user's inbox). 
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In considering claim 7, L'Heureux, further discloses that confirming that the 
instructions have been downloaded by a proxy agent includes receiving an 
acknowledgment from the proxy agent that the instructions have been received (col. 8, 
lines 47-50, wherein the proxy agent is the user's e-mail program and it sends a 
confirmation message to the sender that the "DET commands have been executed 
properly"). 

In considering claim 8, L'Heureux further discloses that the mail server sends the 
proxy agent instructions to a proxy agent mail server from which the proxy agent may 
download the instructions (col. 6, lines 4-5, 13-14, 20-22, "SMTP sen/er 130 then 
transfers the e-mail message to the target recipient's POP server 160," and "the e-mail 
message will be downloaded in the customary manner"). 

In considering claim 9, L'Heureux further discloses that the proxy agent 
downloads the instructions directly from the mail server (col. 5, lines 5-6, "the SMTP 
server 130 and the POP server 160 may be co-located" such that the messages are 
downloaded directly from the SMTP server). 

In considering claim 10, L'Heureux further discloses that the proxy agent 
instructions are associated with a session identifier (col. 9, lines 4-10, wherein the "Data 
type x-clipmail identifies an e-mail message segment containing DET commands"). 
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In considering claim 11, L'Heureux further discloses that the proxy agent 
instructions are associated with a session identifier and wherein the session identifier is 
used to identify the proxy agent instructions downloaded by the proxy agent (col. 9, 
lines 4-10, wherein the "Data type x-clipmail identifies an e-mail message segment 
containing DET commands"). 

In considering claim 13, L'Heureux discloses a method of receiving network 
device instructions ("commands") for a network device ("DET") comprising: 

Downloading a message from a mail server (col. 6, lines 12-14, "the next time the 
target recipient logs into the POP server 160 for an e-mail session, the e-mail message 
will be downloaded"), the message including the network device instructions (col. 5, 
lines 55-67, "command"); 

Authenticating the message (col. 8, lines 4-5, "the decryption module 322 
validates the message"); and 

Parsing the instruction (col. 8, lines 5-6, "the parser module 312 separates the 
message into command data blocks"). 

In considering claim 14, L'Heureux further discloses that the network device 
instructions are derived from instructions generated by an application (col. 5. lines 40- 
41, 55-60, "GUI software"). 
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In considering claim 15, L'Heureux further discloses sending an acknowledgment 
that the instructions have been received (col. 8, lines 47-50, "return e-mail message 
confirming that the embedded DET commands have been executed properly," and thus 
implicitly confirming that the instructions have been received). 

In considering claim 16, L'Heureux further discloses executing the instructions 
and uploading the results to the mail server (col. 8, lines 47-50, "generates and sends 
return e-mail message confirming that the embedded DET commands have been 
executed properly"). 

In considering claim 17, L'Heureux further discloses managing a network 
according to the network device instructions (col. 4, lines 10-15; col. 5, lines 33-46, 
wherein configuring the remote computer constitutes managing the network). 

In considering claim 18, L'Heureux further discloses gathering network data 
according to the network device instructions and reporting the results (col. 8, lines 47- 
50, wherein the network device "generates and sends return e-mail message confirming 
that the embedded DET commands have been executed properly" thereby gathering 
data regarding the results of the command and reporting the results to the sender). 
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In considering claim 19, L'Heureux discloses a proxy agent manager ("PC") for 
sending network device instructions ("commands") to a network device ("DET") 
comprising: 

An application interface ("command formatter 220") configured to receive an 
application instruction ("command") generated by an application ("GUI," col. 5, lines 25- 
30,40-41, 55-60); and 

A mail server interface ("SMTP server 130") configured to upload proxy agent 
instructions derived from the application instructions to a mail server and configured to 
confirm that the proxy agent instructions have been downloaded by a proxy agent (col. 
6, lines 1-5, 20-22, 29; col. 8, lines 47-50, wherein the server uploads the instructions 
and wherein the proxy agent at the DET responds with a confirmation through the same 
e-mall servers). 

In considering claim 20, L'Heureux discloses a network device for executing 
instructions from a remote manager comprising: 

A mail server interface configured to download a message from a mail server 
(col. 6, lines 12-14, "the next time the target recipient logs into the POP server 160 for 
an e-mail session, the e-mail message will be downloaded"), the message including the 
Instructions (col. 5, lines 55-67, "command"); and 

A processor configured to authenticate the message and to parse the instructions 
(col. 8, lines 4-6, "the decryption module 322 validates the message, the parser module 
312 separates the message into command data blocks..."). 
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Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
L'Heureux, in view of features that are well known in the art. 

In considering claim 12, although L'Heureux discloses using decryption and 
security keys to encrypt and secure messages sent across the network, L'Heureux does 
not disclose the use of a firewall, such that the network device is behind a firewall as 
claimed. Nonetheless, Examiner takes Official notice that the use of Firewalls on the 
Internet and over e-mail systems is well known in the art (for instance, the USPTO e- 
mail system has used firewalls for security since at least 1999). Given this knowledge, 
a person having ordinary skill in the art would have readily recognized the desirability 
and advantages of placing the network device taught by L'Heureux behind a firewall to 
increase security and prevent hackers from accessing the device. Therefore, it would 
have been obvious to place the DET taught by L'Heureux behind a firewall. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Bradley Edelman whose telephone number is 703-306- 
3041 . The examiner can normally be reached from 9 a.m. to 5 p.m. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess can be reached on 703-305-4792. The fax phone number for 
the organization where this application or proceeding is assigned Is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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General 



1 General 

In contrast to Reliant UNIX, the Emanate Master Agent on Solaris should be 
viewed in combination with the Solaris Master Agent (Solaris Sun Solstice 
Enterprise Master Agent). Both Master Agents are connected by the Siemens 
Native Agent Adapter, which hangs as a Subagent on the Emanate Master 
Agent and passes SNMP requests to the Solaris SNMP Agent on the same 
machine. 



Emanate Master Agent 



SNMP Management Application 



I 



Emanate Subagent 
Native Agent Adapter 



I 



Solaris Master Agent 



The Emanate Master Agent thus takes over some of the tasks of the Solaris 
Master Agent, but does not replace it completely. MIB objects, which are 
supported by the Master Agent or one of its Subagents, will continue to be 
supplied exclusively by this agent. This refers, for example, to all MIB objects in 
the MIB2 tree under Solaris. 

The Solaris Master Agent must open Port 161, on which SNMP requests are 
received, for this purpose. The Emanate Master Agent takes over this port, 
while the Solaris Master Agent awaits SNMP requests directed to it on another 
port (default is 8151). The Native Agent Adapter sets up a connection to this 
Solaris Master Agent port. The MIB objects, for which the Native Agent Adapter 
is to establish contact with the Solaris Master Agent, are defined in a configu- 
ration file. 

In the standard version, this relates to all objects in mib_2 and in the sun tree: 
read 1.3.6.1.2.1 (mib_2) 
read 1 .3.6. 1 .4. 1 .42 (sun) 
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General 



SNMP requests that relate to MIB objects in mib_2 or in the sun tree are thus 
passed directly from the Ennanate Master via the Native Agent Adapter to the 
Solaris Master Agent. The configuration file likewise defines whether read or 
also write access is enabled to these MIB objects. Read access is supported 
exclusively in the standard version. 

If write access is also required to these objects, "read" must be replaced with 
"readwrite" (see man page adaptagt(IM))). 

Irrespective of the type of SNMP request to the Emanate Master Agent (v1 , v2* 
or v3), the Native Agent Adapter generates an SNMPvl request to the Solaris 
Master Agent. The community string, used here is generally 

• publ i c as read community and 

• pri vate as write community. 

If the Solaris Master Agent expects other communities, the Native Agent 
Adapter must be restarted with the appropriate values (see man page 
adaptagt(IM)). 

The functionality of the Solaris Master Agent and its Subagents is preserved 
following connection to the Emanate Master Agent. If, for example, the mib2 
Subagent rejects write access to its objects under Solaris, then it is also not 
possible to modify these objects via the Emanate Master Agent and the Native 
Agent Adapter. For information on the Solaris components, see the documen- 
tation under Solaris (e.g. man page snmpdx(1M) and man page mi bi i sa(1M)) 
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1 Converting Existing SNMP 
Configurations 

SNMP Research Release 15.1 (SMAWsnmpm 1.3) software supports the 
SNMPv3 Administration Framework. Previous releases of the same software 
used different administration frameworks. This chapter describes the steps 
necessary to update an existing SNMP configuration for Release 15.1 
(SMAWsnmpm 1.3). 

1.1 SNMPvl Administration Framework 

SNMP Research products in and before Release 11.x) implemented the 
SNMPvl Administration Framework. Starting with Release 12.1 (SMAWsnmpm 
1.0), SNMP Research products which were compiled to support only the 
SNMPvl protocol (and later SNMPv2c) could optionally use the SNMPvl 
Administration Framework as a simple alternative to the SNMPv2 configuration. 

In SNMP Research products, the SNMPvl authentication information is only 
used by SNMP entities which have a command responder application and/or a 
notification originator application. Authorization information is only used by 
SNMP entities which have a command responder application. Since these kinds 
of applications are usually found only in "agent" entities, the configuration infor- 
mation in the SNMPvl Administration Framework is located only in the 
^nm/7i/x7i/'configuration file. 

When the snmpd.cnfiWe to be converted contains only SNMPvl configuration 
information, there are two kinds of configuration entries which are important. 
These are the community entry and the trap entry. 

1.1.1 Converting community Entries 

An entry that begins with the commmityTIKG contains a community string which 
can be used by "manager" entities to gain access to the MIB in the "agent" 
entity. The format of the VALUE clause is: 

community-name IP-address privileges community-id 

The fields in a community entry should be converted as follows: 
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communi ty-name 

is the community string. First, this string should appear in the community- 
Name field of a communityEntry entry. The communityGroupName field of 
this communityEntry entry must contain a valid vacmGroupName (READ or 
WRITE in the example below). See the man page snmpd . cnf (4) for more 
information. 

As an example, if the community-name is publ i c, the communityEntry 
might be: 

communityEntry localSnmpID public READ localSnmpID default - nonvolatile 

Next, the community string must be assigned as a principal to an access 
control group. The community string should appear in the vacmSecuri- 
tyName field of a vacmSecurityToGroupEntry entry. The vacmSecurity Model 
field of this vacmSecurityToGroupEntry entry should be snmpvl to make 
the string be an SNMPvl community string, or sninpv2c to make the 
string be an SNMPv2c community string. To make this string be both an 
SNMPvl and an SNMPv2c community string, create two vacmSecurityTo- 
GroupEntry entries. See the man page snmpd . cnf (4) for more infor- 
mation. 

Continuing with the example above, there may be two vacmSecurityTo- 
GroupEntry entries: 

vacmSecurityToGroupEntry snmpvl public READ nonvolatile 
VacmSecurityToGroupEntry snmpv2c public READ nonvolatile 

IP-address 

indicates the remote site for which this community is valid. If the IP 
address is 0 . 0 . 0 . 0, the communityTransportLabel field of the community- 
Entry entry should be a dash (-). If the IP address is not 0 , 0 . 0 . 0, this 
address should appear in the snmpTargetAddrTAddress field of an snmpTar- 
getAddrEntry entry, and the value of the communityTransportLabel field of 
the communityEntry entry should appear in the list of (space-separated) 
tags in snmpTargetAddrTagList field of the snmpTargetAddr Entry entry. 
Additionally, the snmpTargetAddrTDomain field should be snmpUDP- 
Domain, and the tgtAddressMaskf\e\6 should be 255.255.255.255:0. 
See the man snmpd . cnf (4) for more information. 

pri vi 1 eges 

is a coarse authorization identifier with an implied MIB view of "see- 
everything" (The SNMPvl Administration Framework supports only a 
trivial access control mechanism). To convert this configuration infor- 
mation, first verify that a vacmViewTreeFamilyEntry entry similar to the 
following exists (create an entry if one does not already exist): 
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vacmViewTreeFamilyEntry All iso - included nonvolatile 

This entry creates a MIB view that is arbitrarily called "All" which includes 
a point just below the root of the MIB tree, iso. 

Next, if the privileges field is READ, verify that vacmAccessEntry entries 
similar to the following exist (create them if they do not already exist): 

vacmAccessEntry READ - snmpvl noAuthNoPriv exact All - - nonvolatile 
vacmAccessEntry READ - snmpv2c noAuthNoPriv exact All - - nonvolatile 

If \\\e privileges field is WRITE, verify that vacmAccessEntry entries similar 
to the following exist (create them if they do not already exist): 

vacmAccessEntry WRITE ~ snmpvl noAuthNoPriv exact All All - nonvolatile 
vacmAccessEntry WRITE ~ snmpvZc noAuthNoPriv exact All All - nonvolatile 

NOTE: 

' ' - The strings READ and WRITE in the new entries are arbitrary 

strings. 

- The correct string (either READ or WRITE in this example) must 
appear in the communityGroupName field of the corresponding 

community Entry, 

- The vacmAccessReadViewName field should identify the "All" 
MIB view. 

- If the privileges field is WRITE, then the vacmAccessWrite- 
ViewName field should identify the "AH" MIB view. 

- The vacmAccessNotifyViewName field can identify the "All" MIB 
view if this community string will also be used for sending Trap 
messages (see the following section. 

community-id 

is unused by the SNMPv3 Administration Framework and does not need 
to be converted, 

1.1.2 Converting trap Entries 

An entry that begins with the trap TAG contains the IP address of an SNMP 
"manager" entity to which an SNMPvl (and later SNMPv2c) Trap is sent. The 
format of the VALUE clause is: 

trap-community-name IP-address 

The fields in a trap entry should be converted as follows: 
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m The trap-community-name is the community string which is sent in the Trap 
message. First, this string should appear in the snmpTargetParamsSecuri- 
tyName field of a snmpTargetParamsEntry entry. 

If the Trap should be sent as an SNMPvl message, the snmpTarget- 
ParamsMPModelf\e\d of the snmpTargetParamsEntry entry should be zero (0), 
the snmpTargetParamsSecurityModel field should be snmpvl , and the snmpTar- 
getParamsSecurityLevelf\e\6 should be noAuthNoPri v. If the Trap should be 
sent as an SNMPv2c message, the snmpTargetParamsMPModel field of the 
snmpTargetParamsEntry entry should be one (1), the snmpTargetParamsSecuri- 
tyModel f\e\6 should be snmpv2c, and {hesnmpTargetParamsSecurityLevelT\e\6 
should be noAuthNoPri v. 

If the Trap should be sent as both an SNMPvl message and as an SNMPv2c 
message, there should be two snmpTargetParamsEntry entries. As an 
example, if the trap-community-name is test2, the snmpTargetParamsEntry 
entry(ies) might be: 

snmpTargetParamsEntry vlExampl eParams 0 snmpvl test2 
noAuthNoPri V \ 
nonVol ati 1 e 

snmpTargetParamsEntry v2cExampl eParams 1 snmpv2c test2 

noAuthNoPri V \ 

nonvolatile 

• The IP-address indicates the destination address of the notification; i.e., 
where to send the Trap. First, this address should appear in the snmpTar- 
getAddrTAddress field of a snmpTargetAddrEntry entry, and the snmpTargetAd- 
drParams field of the snmpTargetAddrEntry entry should be the same as the 
snmpTargetParamsSecurityName field of the snmpTargetParamsEntry entry(ies). 
Additionally the snmpTargetAddrTDomain field of the snmpTargetAddrEntry 
entry should be snmpUDPDomai n, the tgtAddressMask f\e\6 should be 
255.255.255.255:0, and the snmpTargetAddrTagList sUou\6 be a unique 
string, such as ConvertedTraps. See the man page snmpd . cnf (4) for 
more information. As an example, if the trap entry is 

trap test2 192.147.142.254 

then the snmpTargetAddrEntry entry(ies) might be: 

snmpTargetAddrEntry MyMgrEntryl snmpUDPDomai n 
192.147.142.254:0 100 3 \ 

ConvertedTraps vlExampl eParams nonvolatile 255,255.255.255:0 
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snmpTargetAddrEntry MyMgrEntry2 snmpUDPDomai n 
192.147.142.254:0 100 3 \ 

ConvertedTraps v2cExampl eParams nonvolatile 255.255.255.255:0 

Next, the unique string which is the value of snmpTargetAddrTagList in the 
snmpTargetAddrEntry entry(ies) should appear in the snmpNotifyTag field of 
a snnnpNotifyEntry entry. The snmpNotifyTypefield of the snnnpNotifyEntry 
entry should be "trap". Continuing with the example above, the new entry 
might be: 

snmpNoti fyEntry 31 Console trap nonvolatile 

Next, verify that a vacmViewTreeFamilyEntryentry similar to the following 
exists (create an entry if one does not already exist): 

vacmViewTreeFamilyEntry All iso - included nonvolatile 

This entry creates a MIB view that is arbitrarily called "AH" which includes a 
point just below the root of the MIB tree, iso. 

Next, the trap-community-name must be assigned as a principal to an access 
control group. The community string should appear in the vacmSecurityName- 
field of a vacmSecurityToGroupEntry entry. The vacmSecurityModelf\e\d of this 
vacmSecurityToGroupEntr)> entry should snmpvl to cause an SNMPvl Trap 
messages to be sent, or snmpvZc to cause an SNMPvlc Trap messages to 
be sent. To cause both SNMPvl and SNMPv2c messages to be sent, create 
two VacmSecurityToGroupEntry entries. See the man page snmpd . cnf (4) for 
more information. Continuing with the example above, there may be two 
vacmSecurityToGroupEntryentries: 

VacmSecurityToGroupEntry snmpvl public TRAP nonvolatile 
VacmSecurityToGroupEntry snmpv2c public TRAP nonvolatile 

Finally, verify that a vacmAccessEntry entry exists which contains the trap- 
community-namein the vacmGroupNamefield, snmpvl or snmpv2c as desired 
in the vacmAccessSecurityModel field. The vacmAccessNotifyViewName field 
should identify the "All" MIB view. If such a vacmAccessEntry entry does not 
exist, create an entry for each type of Trap message (SNMPvl or SNMPv2c) 
to send. For example: 

vacmAccessEntry TRAP - snmpvl noAuthNoPriv exact — All nonvolatile 
vacmAccessEntry TRAP - snmpvZc noAuthNoPriv exact — All nonvolatile 

The string TRAP in the new entries is an arbitrary string. If the same 
community string will be used to send Traps as well as to generate 
Get, Set, etc. SNMP request, one can simply set the vacmAccessNoti- 
fyViewName field in an existing vacmAccessEntiy entry to the "All" MIB 
view. 
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1 .2 Party=based SNMPv2 Administration 
Framework 

SNMP Research products from Release 12.1(SMAWsnmpm 1.0) to Release 
12.3 (SMAWsnmpm (SMAWsnmpm 1.0) implemented the Party-based 
SNMPv2 Administration Framework. Today, both the protocol and security 
administration framework of Party-based SNMPv2 have moved to the Historic 
state and is no longer supported. 

In the Party-based SNMPv2 Administration Framework, a party was an encap- 
sulation of the security information necessary to perform authentication and 
privacy operations. In the SNMPv3 Administration Framework, a user serves the 
same purpose. However, the configuration information for parties can not be 
easily converted into configuration information for users. This section describes 
how to understand SNMPv2 parties well enough to dermine the IP address(es) 
of the "manager" entities which may have sent requests to or received Traps 
from the agent. 

In a bilingual SNMP agent of the period, a special kind of party, called an 
rfcll57Domain party, contained an SNMPvl community string instead of 
SNMPv2 authentication and privacy information. This section also describes 
how to understand rfcl 1 57Domain parties well enough that the same 
community strings can be configured in the SNMPvS Administration 
Framework. 

1.2.1 Configuration Files 

SNMP Research entities which implemented the Party-based SNMPv2 Admin- 
istration Framework did not store the SNMP configuration information in the 
snmpd.cnff\\e. Instead, these entities used configuration files with names ending 
with the extension . pty. Also, the format and usage of the wgr.cn/file was 
radically different than in Release 15.1 (SMAWsnmpm 1.3). 

The discussion of the Party-based SNMPv2 Administration Framework in this 
section will be limited to the following file: 

agt.pty 

The following files should be discarded: 

acl . pty 
context . pty 
mgr . cnf 
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mgr.pty 
vi ew. pty 

1.2.2 Deciphering Network Address Information 

This section describes how to determine the IP address of the SNMP "manager" 
and "agent" entities from the configuration information for SNMPv2 parties in 
the agt.pty file. Each entry in the agt.pty file consists of seven lines: 

PartyName PartyDi scri mi nator 

TDomain TAddress Port Lifetime MaxMsgSize 

partylndex partyStorageType partyLocal partyAuthCl ock 

AuthPublicSecret 

AuthPri vateSecret 

Pri vPubl i cSecret 

PrivPri vateSecret 

The following fields contain useful information: 

TAddress 

This field contains an IP address for the party, but the purpose of the 
address depends upon the TDomain and partyLocal fields: 

• When TDomain is rfcll57Domai n, this field, in conjunction with the 
PoA-/ field, defines a Trap destination address. This field is also used 
for source address authentication for SNMPvl requests. 

• When TDomain is snmpUDPDomai n and /?ar(vIoca/ is fal se, this field 
contains the IP address of a remote SNMP entity. Usually, this remote 
entity is the SNMP "manager" which contains the command 
generator application and/or notification receiver application. 

• When TDomain is snmpUDPDomai n and partyLocal is true, this field 
contains the IP address of the local SNMP entity (the "agent"). 

partyLocal 

This field is meaningless unless the TDomain Is snmpUDPDomai n. For 
snmpUDP Domain, the values are: 

• true: the IP address in TAddress is for the 'local' host 

• f a1 se: the IP address in TAdress Is not the 'local' host, but It is the 
address of a remote SNMP entity. 

An example party table entry is shown here: 
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initial Party Id. 192.147.142.16.2 3 
snmpUDPDomain 192.147.142.16 162 300 1458 
2 nonvolatile false 0 

74 68 69 73 74 68 69 73 74 68 69 73 74 68 69 34 



In the example entry above: 

# The TDomain is snmpUDRDomai n, indicating that this is a SNMPv2 party. 

# The TAddress is 192 , 147 . 142 . 16, indicating that an SNMP entity existed on 
the machine whose IP address is 192 . 147 . 142 . 16. 

# Since partyLocal is f al se and it is a SNMPv2 party, the TAddress field 
contains the IP address of a remote SNMP entity, probably the SNMP 
"manager" which contains the command generator application and/or notifi- 
cation receiver application, 

1.2.3 Deciphering Community String Information 

This section describes how to locate SNMPvl community strings within the 
configuration information for SNMPv2 parties in the agtpty file. Each entry in the 
agt.pty file consists of seven lines: 

PartyName PartyDi scrimi nator 

TDomain TAddress Port Lifetime MaxMsgSize 

partylndex partyStorageType partyLocal partyAuthCl ock 

AuthPubl i cSecret 

AuthPri vateSecret 

Pr i vPubl i cSecret 

Pri vPri vateSecret 

The following fields contain useful information: 

TDomai n 

This field will contain rfcl ISJDomain to indicate that this is an SNMPvl 
community entry in the party table. 

AuthPri vateSecret 

When TDomain is rf cll57Domai n, this field contains community string 
stored as a series of hexadecimal numbers. Each number is the ASCII 
value for the corresponding character in the community string. For 
example, the entry would be 70 75 62 6c 69 63 for the community 
string publ i c. 
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An example party table entry is shown here: 

initial Party Id. 192.147,142.16.31 1 
rfcll57Domain 192.147,142.16 162 300 1458 
31 nonvolatile true 0 

70 75 62 6c 69 63 



In the example entry above: 

• The TDomain is rf cll57Domai n, indicating that this is an SNMPvl 
community entry in the party table. 

• The TAddress and Por/^ fields indicate that traps should be sent to port 162 at 
IP address 192 . 147 . 142 . 16. This field also indicates that SNMPvl packets 
will only be accepted if they come from 192.147.142.16. 

The ^w///Pnva/e5'ecrer contains the community name: 0 75 62 6c 69 
63,which decodes to publ i c. 



1 .3 SNMPv2* Administration Framework 

SNMP Research products from Release 14.1 to Release 14.2 (SMAWsnmpm 
1.1 and 1.2) implemented the SNMPv2* Administration Framework. This 
framework, like its successor the SNMPv3 Administration Framework, encapsu- 
lates the security information necessary to perform authentication and privacy 
operations into the familiar concept of "users" and "passwords." This similarity 
allows configuration information from the SNMPv2* Administration Framework 
to be easily converted into configuration information for the SNMPvS Adminis- 
tration Framework. 

With Release 15.1 (SMAWsnmpm 1.3) software products, SNMP Research 
provides a program which automatically converts configuration files from the 
earlier releases implementing the SNMPv2* Administration Framework. The 
following section describes this conversion program and its use. 

The cfgcvt Configuration Conversion Program 

The cfgcvt configuration conversion program reads an SNMP Research SNMP 
configuration file (ending with extension . cnf ) as input and creates a new 
configuration file (ending with extension . new) for use by SNMP entities which 
implement the SNMPvS Administration Framework. 
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The new configuration file must be manually renamed with the .cnf extension 
before it can be used by SNMP Research software. 



► cfgcvt ► 

prefix/ snmpd , cnf prefix/ snmpd . new 

Figure 5: The default behavior of cfgcvt 
Defaults 

The c/gcv/ assumes that the input file to convert is called snmpd . cnf, the output 
file to create is called snmpd . new, and that the filename prefix (directory path 
name) is /etc/srconf /agt on UNIX systems. Figure 1 shows the default 
behavior 



Command Line Arguments 

The behavior of the cfgcvt program is modified by the following command line 
options. 

-agt 

Converts the configuration file used by SNMP Research SNMP "agent" 
entities. This is the default. 

-mgr 

Converts the configuration file used by SNMP Research SNMP 
"manager" entities. When the -mgr command-line is used with cfgcvt, the 
default input file name changes to mg r . cnf, the default output file name 
changes to mgr . new, and the default prefix changes to 



I 1 — — ► cfgcvt 

prefix/mgr . cnf 

Figure 6: The behavior of cfgcvt with the -mgr option 



prefiix / vagr ,neyj 
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J ~ — — cfgcvt 

prefix/ filename 

Figure 7: The behavior of cfgcvt with the -in option 



j ► cfgcvt 

prefix / snmpd.cnf prefix I filename 

Figure 8: The behavior of cfgcvt with the -out option 

The filename prefix (directory path name) is /etc/s rconf /mgr on UNIX 
systems. Figure 2 depicts the modified behavior 

-i n filename 

Changes the name of the input file to filename. Figure 3 depicts the 
modified behavior. 

-out filename 

Changes the name of the output file to filename. Figure 4 depicts the 
modified behavior. 

-pref i X directory 

Changes the prefix to directory This command line argument overrides 
any environment variables which may be set. 

Environment Variables 

The behavior of the cfgcvt program is modified by the following environment 
variables. 

SR_MGR_CONF_DIR 

This environment variable changes the prefix to the input file when the - 
mgr command-line argument is being used. 

SR_AGT_CONF„DIR 

This environment variable changes the prefix to the input file when the 
defaults are being used or when the -agt command-line argument is 
being used. 



prefix I snmpd . new 
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Note that the value of these environment variables may be overridden 
with the -prefix directory command-line argument. 



Using cfgcvt on UNIX Systems 

Before running cfgcvt on UNIX Systems, perform the following steps. 

1 . Become root. The program must be started by superuser. 
% su 

2. Specify the location of the mgr.cnfconfigu ration file: 

#setenv SR_MGR_CONF_DIR /etc/srconf /mgr 

To start cfgcvt, type the program' s name followed by any desired command-line 
arguments. 

% cfgcvt 

Understanding Warning Messages 

This section explains the warning messages which may be generated by cfgcvt. 



WARNING 
WARNING 
WARNING 
WARNING 



***************************************************** 
There are v2ContextEntry lines in the input file. 
These cannot be converted to the output file. 



The cfgcvt program prints the above message if it finds one or more 
v2ContextEntty tags in the input file. The definition of context information differs 
between the SNMPv2* Administration Framework and the SNMPv3 Adminis- 
tration Framework and can not be converted. 

WARNING • ***************************************************** 
WARNING: There are acEntry lines in the input file which 
WARNING: contain non-empty acContextNameMask values. 
WARNING: These cannot be converted to the output file. 
WARNING: You may wish to hand-edit the resulting output 
WARNING: file and change some of the vacmAccessEntry lines 
WARNING: to use a 'prefix' value for vacmAccessContextMatch . 
WARNING* **************************************************** 

The cfgcvt program prints the above message if it finds one or more acContext- 
NameMaskf\e\6s in the input file which contain a value other than a dash (-). The 
definition of context name 'wildcards' differs between the SNMPv2* Adminis- 
tration Framework and the SNMPv3 Administration Framework and requires 
human intervention to be converted. 
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WARN I N6" **************************************************** 

WARNING: There are notifyEntry lines in the input file. 

WARNING: If multiple entries contain the same 

WARNING: noti fy Identi tyName and noti fyContextName 

WARNING: values, but different noti fyVi ewName values. 

WARNING: the extra noti fyVi ewName values will not be used 

WARNING: in the output file. 

WARN I NG ■ **************************************************** 

The cfgcvt program prints the above message if it finds one or more notifyEntry 
TAGS in the input file. The notifyEntry entries can be automatically converted, but 
if more than one notifyEntry entry exists with the same identity and context but 
different MIB views, only the first MIB view is retained in the output file. 

BackupFile: Warning, cannot backup config file. 

at line 1899 in file scanfile.c 
WriteConfigFile: Warning, cannot backup config file. 

at line 1736 in file scanfile.c 

The cfgcvt attempts to make a backup copy of converted configuration before 
starting the conversion process. The first time cfgcvt is executed for a particular 
directory, a converted file does not already exist, so the above message is 
printed. This message could also mean that the output file from a previous 
conversion exists, but it can not be overwritten. 

OpenConfigFile: can't open /etc/srconf /agt/snmpd . cnf with mode 1 

at line 207 in file k_fileio.c 

The cfgcvt program does not have sufficent permission to open the configuration 
file for reading, or the file does not exist in the named directory. 

OpenConfigFile: can't open /etc/srconf /agt/snmpd . new with mode 2 

at line 207 in file k_fileio.c 

The cfgcvt program does not have sufficent permission to open the output file for 
writing. 

WriteConfigFile: WARNING. CANNOT RESTORE OLD CONFIG FILE 

at line 1850 in file scanfile.c 

This message means that the directory containing the original configuration file 
is not writable by cfgcvt. The original file is never modified by cfgcvt, so no config- 
uration information from the original file is lost. 
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MAYNARD, Mass. --(BUSINESS WIRE)-Feb. 8, 1999-- 

Agranat Systems and SNMP Research International Integrate Technologies 

Accelerating Development of Web-based SNMP Management Solutions 

Agranat Systems, Inc., the market leader in embedded Web server technology, today 
announced an agreement to integrate EmWeb/NM with SNMP Research International's 
Master Agent EMANATE(R). By coupling the technologies, a Web browser can access 
SNMP-based management information directly through EMANATE. The aWiance permits 
original equipment manufacturers to quickly and easily develop Web-based interfaces 
that access SNMP data without writing additional code. 

Because EmWeb/NM delivers the full power of simple network management protocol 
(SNMP) management to the Web by leveraging existing management information bases 
(MIBs), developers are spared months of re-coding. EmWeb/NM's fully compliant HTTP 
1.1 server ensures that any authorized browser can access a networking product from 
anywhere on the network. Joined at inception, EmWeb/NM with EMANATE accelerates 
Web-based network management solution development. 

"The integration of EMANATE with EmWeb/NM provides a revolutionary means for 
manufacturers to capitalize on the management applications of the Web," said Jeff 
Case, founder and CTO of SNMP Research International. "For the first time datacom 
equipment manufacturers have the industry leading tools to create efficiently managed 
networks via the Web. SNMP Research is pleased to partner with a vendor of Agranat's 
integrity and technological leadership." 

Datacom and network equipment manufacturers now have the tools to create solutions 
that configure, manage and monitor systems using a familiar Web interface. 
EmWeb/NM employs a variety of unique development techniques to accelerate the 
creation of dynamic Web pages without requiring CGI-based applications. Providing 
numerous management choices, EmWeb/NM is compatible to a \/ahety of network 
systems. Industry leaders and innovators recognize that EmWeb/NM's C compiled 
embedded server provides the smallest, most efficient implementation available. 
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"The integration of the technologies will further decrease datacom OEM's time-to- 
market for their Web managed products" said Ian Agranat, president and CEO of 
Agranat Systems. "As we look forward to a long-standing relationship with SNMP 
Research, Agranat is committed to supporting all future versions of EMANATE and will 
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About SNMP Research International: 

SNMP Research International offers network management solutions, by supplying SNMP 
software products including the following: the EMANATE Extensible Agent system; 
security configuration and customization tools for HP OpenView; a Packaged Agent 
System designed to ease the OEM's task of adding manageability to embedded 
systems; intelligent agent Mid-Level Managers; and specialized MIB implementations of 
IETF standards including the SysAppI MIB, Host Resources MIB, RMON, UPS, and 
others. 

In addition, the company's new Legacy Adapter to Internet (LATIN) class of products 
provides an affordable solution to managing legacy systems under an SNMP framework. 
LATIN translates legacy system messages and alarms to SNMP format without requiring 
custom-built MIBs or agents. 

Interoperability, simplicity, robustness, and portability are hallmarks of SNMP Research 
International products. The company has achieved significant worldwide market 
penetration with hundreds of multi-national, long-standing customers shipping 
thousands of SNMP-capable products and services based on SNMP Research code. 
Founded in 1988, SNMP Research is a well-established leader in developing and 
supporting standards-based management technology. 

For more information about SNMP Research's products and services, contact them by 
phone at their headquarters in Knoxville TN at 423-579-3311, or by e-mail at 
info@int.snmp.com. You may also access their Web site at www.int.snmp.com. 

About Agranat Systems, Inc. 

Agranat Systems Inc. is a software development company specializing in embedded 
Web technologies for datacomm, telecomm, imaging and other manufacturing 
industries seeking to provide added value and competitive advantages for their 
products and customers by implementing Web-based management capabilities. 
Organizations that have licensed EmWeb technology include Hewlett-Packard, Bay 
Networks, 3Com, Nortel, Compaq, Lucent, Nokia, Cabletron and many other companies 
worldwide. Agranat Systems is a member of the WoHd Wide Web consortium (W3C) 
and the Desktop Management Task Force (DMTF) and actively participates on the 
Internet Engineering Task Force (IETF) for Web standards development. To learn more 
about Agranat and EmWeb, please visit Agranat's web site: http://www.agranat.com. 
You may also call corporate headquarters at 1 (978) 461-0888, the Mountain View, CA 
sales office at 1 (650) 903-2233, or send E-mail to sales@agranatxom. 

COPYRIGHT 1999 Business Wire 
COPYRIGHT 2000 Gale Group 
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